In electronic devices and computer networks generally, many resources are shared or are otherwise subject to multiple access requests. Some mechanism is usually employed to handle these multiple access requests without causing data corruption and/or other errors due to uncoordinated accessing and unmanaged interference. The mechanism that is usually employed is a locking mechanism.
FIG. 1 illustrates an existing general locking scheme for accessing resources. A device 101 includes a resource 103. Resource 103 is, by way of example, a database. Device 101 also includes an acquire lock (AL) function 105 and a release lock (RL) function 107. Acquire lock 105 and release lock 107 facilitate the acquisition and release, respectively, of locks on resource 103 during the servicing of access requests 109.
A legend for FIG. 1 indicates that threads are represented by diagonal squiggly lines and that APIs are represented by rectangles. Hence, acquire lock 105 and release lock 107 are APIs. Access requests 109, on the other hand, are represented by squares. Access requests 109 include access request 109(1), access request 109(2), and access request 109(3).
At (1), acquire lock 105 enables a lock to be secured on resource 103 for access request 109(1) on behalf of the thread thereof. At (2), the thread of access request 109(1) accesses resource 103. At some point after a lock is secured on resource 103 at (1), access request 109(2) is accepted by acquire lock 105. Because resource 103 is already locked, the thread of access request 109(2) is suspended at (3). Similarly, when access request 109(3) is received, acquire lock 105 also causes the thread of access request 109(3) to be suspended at (4).
When the thread of access request 109(1) completes the accessing of resource 103, release lock 107 releases the access lock on resource 103. At (5), release lock 107 causes a thread that has been suspended to be awakened so that the access request 109 thereof may be serviced by enabling access to resource 103. With this general locking scheme of FIG. 1, resource 103 may be locked regardless of whether an access request 109 is a read from or a write to resource 103.
FIG. 2 illustrates an existing reader/writer locking scheme for accessing resources. Device 101 again includes resource 103. However, acquire lock 105 and release lock 107 are divided into read and write logic. Specifically, acquire lock 105 is divided into acquire reader lock (ARL) 105(R) and acquire writer lock (AWL) 105(W). Release lock 107 is divided into release reader lock (RRL) 107(R) and release writer lock (RWL) 107(W).
Access requests 109 are also divided into read access requests 109(R) and write access requests 109(W). Specifically, two read access requests 109(R1) and 109(R2) and two write access requests 109(W1) and 109(W2) are shown. Because read access requests 109(R) do not modify resource 103, multiple read access requests 109(R) may be concurrently serviced. Hence, at (1) multiple concurrent reads are permitted by acquire reader lock 105(R).
While resource 103 is locked to service one or more reads, threads of write access requests 109(W) are suspended at (2) by acquire writer lock 105(W). The completion of all reads is awaited at (3). After all reads are completed, release reader lock 107(R) releases the lock on resource 103 and at (4) awakens a previously-suspended write thread.
At block (5), a thread for write access request 109(W1) is awakened. Acquire writer lock 105(W) locks resource 103 at (6). At (7), write access request 109(W1) writes to resource 103. Upon completion of the write, release writer lock 107(W) unlocks resource 103 and at (8) awakens the thread for the next write request 109(W) (e.g., write access request 109(W2)). Although this reader/writer locking scheme enables concurrent read accesses to expedite the overall handling of both read and write access requests 109, it still entails significant overhead.
Accordingly, there is a need for schemes, mechanisms, techniques, etc. that can efficiently facilitate the handling of access requests while reducing attendant processing overhead.